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This work presents a model -based development methodologj^Jfor verified software systems as well 
as a tool support for it: an applied AutoFocus 3 tool chain and its basic principles emphasizing the 
verification of the system under development as well as the check mechanisms we used to raise the 
level of confidence in the correctness of the implementation of the automatic generators. 



1 Introduction 



Software-based system development has become one of the most challenging fields of software engineer- 
ing research and industrial application. To support the contemporary system development in industry 
CASE tools are used - they allow a simple and (mostly) intuitional design of distributed systems and 
applications, and executable code is generated directly from the models developed using these tools. In 
state-of-the-art industrial development, quality assurance is performed by extensive testing of the gen- 
erated code. However, testing can only demonstrate the absence of errors for exemplary test cases, but 
not the correctness of the system. In opposite to testing, formal verification delivers a correctness proof 
for safety critical properties but requires significant effort. Thus, only the most critical parts of a system 
must be verified, and the whole process of specification and verification must be set up in a way that 
minimizes the overall effort - the verification process must be integrated into model-based development 
of safety-critical systems. On the other hand, testing and simulation must belong to the development 
process, because in some cases, even after verifying certain properties, inconsistencies can still remain 
in the specification, model or code - most often an important property is overlooked as nicely stated by 
Donald E. Knuth's famous saying: "Beware of bugs in the above code - I have only proved it correct, 
not tried it." 

There is a number of works on integration of different system models and verification techniques. 
For instance, the Ptolemy approach (see [7]) introduces a general way to combine heterogeneous models 
of embedded systems. A prominent example of integration of verification techniques is a combination 
of Model Checking and Deduction for I/O-Automata done by O. Miiller and T. Nipkow (see ifTolO . 
However, to our best knowledge there are no other works on achieving a pervasive formal development 
process for embedded applications starting with informal textual specification and leading to verified 
machine-code. This direction has been touched for the first time in [3], though only for upper layer of 
automotive systems and focused on later verification phases - in contrast, the contribution of the work 
presented here is covering the entire seamless pervasive development process. 

The first steps towards a methodology for development of verified embedded system have been done 
in |@J|51. For example, a typical setting found in the automotive domain, a time-triggered operating and 
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Figure 1 : Development Methodology 



communication bus system, has been verified Ifl4l l3l. In this paper we deal with the verification of the 
application software. In comparison to the problem frame approach of M. Jackson [13] as well as the 
4- variable model of Parnas and Madey lTT8l . we present a pervasive formal development methodology for 
embedded systems starting from an informal textual specification of the requirements and going all the 
way to verified application code. Earlier results of the Verisoft project [31 have shown the methodology 
for later verification phases, in particular the relation between the application model and its execution 
environment, e.g. the operating system. 

We outline here a development methodology for safety-critical systems with focus on the tool chain, 
which is employed in the design, implementation and verification phases of the methodology. The tool 
chain emphasizes verification of the system under development - it not only allows integration into the 
process of modeling, but also reduces the verification and integration effort. 



2 Development Methodology 

Fig. [T] illustrates the structure of the development methodology in a top-down manner: from an informal 
specification through multiple transformation steps we get a verified formal specification, a verified ex- 
ecutable model and also a verified C code implementation. The boxes represent development artifacts, 
the dark arrows show the dependency relations, i.e., which artifact is used as input for the development 
of the successor artifact. The light arrows show the proof relations between the artifacts. 

Beginning with a requirements specification (we focus here only on functional requirements, includ- 
ing timing aspects), which captures the relevant aspects of the system to be developed in flexible yet 
informal way, we derive a tabular semi-formal specification. This first step raises the level of precision 
by transforming the free text requirements into a structured form using specific pre-defined syntactic pat- 
terns as presented in [9]. An informal specification consists of a set of words, which can be distinguished 
into two categories: content words and keywords (relation words). Content words are system-specific 
words or phrases, e.g. "system is initialized" or "Off-button is pressed". The set of all content words 
forms the logical interface of the system, which can be understood as some kind of (domain specific, 
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system-dependent) glossary that must be defined in addition. Keywords are domain-independent and 
form relationships between the content words (e.g. "if", "then", "else"). A semiformal specification 
consists of a number of requirements described using the following textual pattern, which is easily be 
understood also by engineers unfamiliar with the formal methods: 



An event describes a point in time, in which the system observes or does something; the duration of 
the event is not important, e.g., "driver presses a button". A state describes a system or component 
state within some time period, e.g., "a button is pressed". Using such a simple description to structure the 
information from the informal specification, we can find out missing information quite fast. Furthermore, 
we identify possible synonyms that must be unified before proceeding to a formal specification. Analysis 
of the semiformal specification document should also yield sentences, which need to be reformulated 
or extended. This specification can be also rewritten to a Message Sequence Charts (MSCs, cf. ifTOl ) 
representation according to the approach presented in [24J. The purpose of using MSCs for specification 
of highly interacting systems is to obtain a better overview in comparison to a textual representation. 

Subsequently, the specifications are translated to FOCUS O, a framework for formal specifications 
and development of distributed interactive systems. FOCUS is preferred here over other specification 
frameworks since it has an integrated notion of time and modeling techniques for unbounded networks 
(where we have replications of system components of the same kind), provides a number of specification 
techniques for distributed systems and concepts of refinement, as well as graphical notation, which is 
extremely important when we are dealing with systems of industrial size. In general we represent in 
FOCUS two kinds of specifications: a formal specification of system requirements and the corresponding 
architecture specification. Both of them are extracted from the MSC specification and/or the semiformal 
specification. This representation prepares the ground to verify the system architecture specifications 
against the system requirements by translating both to the theorem prover Isabelle/HOL iTTTl via the 
framework "FOCUS on Isabelle" (23). 

As the next step, we translate the architecture specification to a representation in the related CASE 
tool AUTOFOCUS 3 ||2T1 |2l to simulate the system. The requirements specification can be translated 
from FOCUS to temporal logic, which gives basis to model-check the model. The transformations from 
FOCUS to temporal logic and to the AUTOFOCUS 3 representation are formal and schematic, given some 
constraints on the FOCUS specification are obeyed. This model can also be exported to Isabelle/HOL to 
prove its properties - it is in general a refinement of a FOCUS specification, thus its properties can be 
slightly different, i.e., more strict, from the ones specified on the FOCUS layer, but the proof schema, 
which has been developed for the FOCUS specifications, can be (partially) reused. 

The last step in our methodology is transformation of the model to a corresponding C code by a code 
generator: we show that the C program is an admissible simulation of the AUTOFOCUS 3 model. This 
concludes our methodology, but that is of course not the end of the complete development process: we 
need to deploy the code into the execution environment. Altogether, the methodology guides us from 
an informal specification via stepwise refinement to a verified formal specification, a corresponding 
executable verified model, and also a corresponding verified C code implementation. 

The applicability of the methodology has been demonstrated by two case studies from automotive 
area. The first case study ||8j|24l, developing an Adaptive Cruise Control (ACC) system with Pre-Crash 
Safety functionality, was motivated and supported by DENSO Corporation, the second case study ll25lL 
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developing a Cruise Control System with focus on system architecture and system verification, was 
supported by Robert Bosch GmbH, Table 1 gives short description how the statistics about these two 
case studies, the size of the AUTOFOCUS 3 model is approximately equal to that of the corresponding 
FOCUS specification. 

In each of the case studies we had a final number of system states was final according to the AiJTO- 
FOCUS 3 modeling paradigm, the most complex component was the component specified the main logic 
of the system. In the case of the Cruise Control System we split the specification of the main system logic 
into four components according to the formal decomposition approach ll25ll introduced within the system 
development methodology. There is a large number of approaches in area of decomposition (see, e.g., 
|[TTll20ll27l ). The main difference and the main contribution of our decomposition methodology is that it 
was developed for such a system architecture, where we already know (or, more precisely, have already 
specified them in a formal way) systems or components properties and need to decompose this whole 
properties collection to a number of subcomponents to get readable and manageable specifications. 

An sample-property proven for the Cruise Control System looks like follows: If the driver pushes 
the Accelerate-button while the system is on and none of the switch-off constraints occurs, the system 
must accelerate the vehicle during the next time unit respectively to the current speed and the predefined 
acceleration schema. This means also that the system must analyze the information from sensors to 
check whether any switch-off constraints occurs, i.e. if the battery voltage is too low or if the gas pedal 
sensor fails. 
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Table 1: Case Studies Statistics 



3 AutoFOCUS 

AUTOFOCUS 3 El EH is a scientific prototype implementing a modeling language based on a graphical 
notation designed to support the modeling of distributed, timed, reactive systems. The tool a restricted 
version of the formal FOCUS semantics, in particular the time-synchronous frame and supports differ- 
ents layers of models, their simulation and analysis. Main aspects of AutoFOCUS 3 are hierarchical 
component decomposition of the system, modeling behavior of application parts of the system as well as 
modeling of technical architectures including control units and communication busses. 

We give a brief introduction of the current language. In particular, we introduce three modeling 
views: data type, system structure, and component behavior specifications. 

Every computer-based system can be seen as a data processing system. Thus programming and 
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modeling languages are based on some mechanism for specifying data items or more general data types. 
AUTOFOCUS 3 uses a functional language to specify data types, this provides a set of predefined types, 
such as Boolean and Integer. Based on these, we can define more complex types using variant or enumer- 
ation types and record-like types. User-defined functions allow us to implement additional operations for 
our data types. 

Although in general data types and user functions may be recursive, we restrict them to be non- 
recursive for the domain of embedded systems, because this eases several tasks. Firstly, we obtain 
statically computable bounds for memory consumption and execution times. For embedded software 
this is often highly desirable, because of restricted hardware resources and the need to respect given 
timing bounds and constraints. Secondly, current model-checkers rely on bounded types. 

The system structure specification is similar to the FOCUS architecture specification. It captures the 
static aspects of the system description. We specify a network of communicating components working 
in parallel (assuming a global synchronized time frame). Each component has a syntactic interface 
described by a set of ports. Each port is either an input or an output port, has a data type and an 
initial value. Furthermore, each component is declared to be weakly causal or strongly causal. Weak 
causality models instantaneous reaction, while strong causality models a delayed reaction. The network 
of components is formed by connecting ports with channels. From the semantics point of view, we need 
to avoid weakly causal feedback loops (Brock-Ackermann anomaly). Fortunately, this can be checked 
easily by the tool's model constraint checker. 

System structure specifications may be separated into hierarchic views n order to deal with larger 
models. Components can be refined into a set of sub-components introducing both local communication 
and communication to the environment, e.g., through the interface of the parent component. 

Atomic components have their behavior specified using one the following variants: a stateful au- 
tomaton specification or a stateless function specification. An automaton specification describes an in- 
put/output automaton. It consists of a set of control states, a set of typed data state variables, and a set 
of transitions. One of the control states is marked as the initial state. Every data state variable is also 
initialized to a given value. 

Each transition has a source and a target control state. Furthermore, each transition specifies patterns 
of messages received via the input ports of the respective component and preconditions over the inputs 
and the data state variables. A transition can fire, if its source state is the current control state, the current 
input values match its input patterns, and the precondition is fulfilled. If a transition fires, the current state 
of the component changes to its target state, the output values of the component are updated according to 
the output pattern specification of the transition, and the data state variables are also updated as specified 
by the postcondition part of the transition specification. Note that more than one transition might be 
enabled for a given component state and set of input port values. Thus, component behavior can be 
non-deterministic. 

Sometimes it is cumbersome to give an automaton specification for simple components. In particular, 
if the component does not need an internal state, a simple mapping from input values to output values is 
convenient. In AUTOFOCUS 3 this is modeled by a function specification. This is a simple table where 
each line defines such a mapping from inputs to outputs. Again, the table can define non-deterministic 
choices. From the semantic point of view function specifications can be seen as restricted automaton 
specifications. 

Using the three views introduced above, we obtain an executable model. We can now validate the 
model using the AUTOFOCUS 3 simulator to get a first impression of the system under development and 
possibly find implementation errors that we introduced during the manual transformation of the FOCUS 
specification into a AUTOFOCUS 3 model. Automatisation of this transformation is an ongoing work. 



22 



Verified System Development 



4 Generation Tool Chain 

Our goal is to establish a sound verification environment with a high confidence in the correctness of the 
environment and thus of correctness the designed system, for this purpose we have combined AutoFo- 
CUS 3 and the theorem prover environment Isabelle/HOL by implementing a generator for the formal 
transformation of the design model into the theorem prover model, as well as a code generator for pro- 
ducing a C code implementation of the design model. 

The central part is the transformation of the design model into the C code, i.e., the implementa- 
tion path of the product under development. This is supported by two verification mechanisms: semi- 
automatic verification with a theorem prover and fully automatic verification by means of a model- 
checker. These flanking measurements fulfill two purposes. On the one hand they verify actual properties 
of the design model and the implementation code, On the other hand differing results of both techniques 
indicate an implementation fault in one of the generators. 

When building a tool chain based on automatic generators it is vital to take great care about what one 
is doing - one must understand the semantics of the generation input, e.g., the AUTOFOCUS 3 model's 
semantics, and the target language, e.g., the C language. Since automatic code generation only makes 
sense, if the behavior of the generated program is equivalent to the behavior of the input model, we must 
show that the transformation is preserving the semantics. We strongly emphasize that the semantics of 
the design language has been defined before implementing the generators. Unfortunately, many code 
generation environments do not follow this up-front approach. They either do not care about behavior at 
all (i.e., generate structural outputs only) or consider the semantics of the generation input to be defined 
by the semantics of the generation outputs (i.e., the semantics of the design model is defined by the 
semantics of the generated code). The first case is of no further interest to us, since the generator only 
produces hull code that needs to be extended manually. The second case forces the user of the input 
language to work around flaws of the generator as we have seen with bugs in compilers. Usually, such 
flaws are exploited by flaws in the developed system, while in our approach the semantics of the design 
language provides the basis for the specification of the generators. 

4.1 The Isabelle/HOL Translator 

Formally specified requirements can be verified using a theorem prover: for this purpose we have devel- 
oped a translator, which generates Isabelle/HOL theories from AUTOFOCUS models. The behavioural 
equivalence between AUTOFOCUS models and their generated representation in Isabelle/HOL has been 
shown in a paper-and-pencil proof fl26l . 

The Isabelle/HOL code for an AUTOFOCUS model is created as follows. Firstly, the user initiates 
code export for the data dictionary, which generates a theory containing data type declarations and func- 
tion definitions used in the model. Then the user may generate code for any of the components in the 
model: when selecting an atomic component, a theory will be generated containing the input/output 
interface definition for the component and the transition function originating from the automaton or 
function specification used to define the component's behaviour; when selecting a composite compo- 
nent, recursively the theories for all subcomponents will be generated and, ultimately, the theory for the 
considered component, whose transition function performs data transmission between the subcompo- 
nents and invokes all subcomponents' transition functions. Generating code for the root component of 
an AUTOFOCUS model yields a set of theory files encoding this model in Isabelle/HOL, as well as proof 
of theorems that support subsequent verification of model's properties in Isabelle/HOL. 



M. Spichkova, F. Holzl, D. Trachtenherz 



23 



4.2 The CO-Code Generator 

In order to obtain executable code from an AUTOFOCUS 3 model, we have implemented a CO code 
generator. A paper and pencil proof (cf. [12]) has shown the behavioral equivalence between the model 
and the generated code. 

CO is a C language subset constructed for usage with the Isabelle/HOL verification environment as 
discussed in l22l . It differs from C by restricting the language - a number of hazardous features, like 
pointer arithmetic, are forbidden in CO, which eases the reasoning and verification with Isabelle/HOL. 
As a result of these restrictions, we gain the advantage of being able to compute memory consumption 
at compile time as well as worst case execution times automatically, since all operations and function 
calls are non-recursive. [19] and lfT5l present the verification of a non-optimizing CO compiler, which 
was itself written in CO with the tool aiT by Abslnt d. 



5 Conclusions and Future Work 

We have presented the model-based development methodology for verified software systems as well as 
the corresponding AUTOFOCUS 3 tool chain to explain how this tool chain and its principles can be 
applied for verification. Our focus was on the design, implementation and the verification phase of the 
overall methodology. The feasibility of the proposed approach has been demonstrated by two industrial 
case studies from automotive area: one case study was motivated and supported by DENSO Corporation, 
the second case study was supported by Robert Bosch GmbH. 

The formal transformations from FOCUS to Isabelle/HOL as well as to AUTOFOCUS 3 are specified 
in the presented methodology as schematic, but not as automatic ones. Automatization of these steps 
is an ongoing work. We are currently also complementing the AUTOFOCUS 3 language with a descrip- 
tion language for distributed execution environments based on embedded control units and bus systems. 
Furthermore, a deployment model combines the logical architecture with the technical architecture, thus 
resulting in a complete description of the executable system. We have to extend our methodology into 
this area by giving suitable verification methods on these new models, as done for a time-triggered oper- 
ating and bus system in lfT4l . 
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